Tools for profiling and tuning application code remain disconnected from the profiling and tuning tools for relational database management systems (RDBMSs). This presents a challenge for developers of database applications to profile, tune and debug applications, for example, identifying application code that causes deadlocks in the server. RDBMSs serve as the backend for many real-world data intensive applications. These applications can use programming interfaces such as ODBC (open database connectivity), JDBC (Java database connectivity), ADO.Net, and OLE DB (object linking and embedding database), for example, to interact with the database server.
When building these applications, application developers can use a variety of tools for understanding and fixing problems in the application. For example, development environments can provide profiling tools that allow developers to understand performance characteristics in the application code such as frequently invoked functions, time spent in a function, etc.
For database application developers, this support is not sufficient since APIs are used to invoke DBMS functionality. Thus, an important part of the application execution happens inside the DBMS. DBMSs provide profiling and tuning tools that give developers information about which SQL (structured query language) statements were executed against the server, the duration of each statement, reads and writes performed by the statement, blocking activity, etc.
However, the information obtained from the development environment profiler and the DBMS profiler remain as two islands of information that have little or no understanding of each other. This makes it difficult for database application developers to identify and fix problems with applications. This is illustrated in one example of detecting functions in the application code that caused a deadlock in the DBMS.
Consider an application that has two threads, each executing a task on behalf of a different user. Each thread invokes certain functions that invoke SQL statements that read from and write to a particular table T in the database. Consider a scenario where an intermittent bug in one of the threads causes SQL statements issued by the application to deadlock with one another on the server. The database server will detect the deadlock and terminate one of the statements and unblock the other. This is manifested in the application as one thread receiving an error from the server and the other thread running to completion as normal. Thus, while it is possible for the developer to know that there was a deadlock (by examining the DBMS profiler output or the server error message) it is difficult for the developer to know, for example, which function in each thread issued the respective statements that caused the server deadlock. Having the ability to identify the application code that is responsible for the problem in the database server can save considerable debugging effort for the developer.